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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Access and Terminals (AT). 

The present document is part 24 of a multi-part deliverable covering Digital Broadband Cable Access to the Public 
Telecommunications Network; IP Multimedia Time Critical Services. Full details of the entire series can be found in 
part 1 [1]. 

The present document describes the ISDN-enabled Multimedia Terminal Adapter (iMTA) architecture and protocols for 
Internet Protocol (IP)-based Cable Telephony ISDN services. 



Introduction 

The cable industry in Europe and across other global regions has already deployed broadband cable television Hybrid 
Fiber/Coaxial (HFC) data networks running the international cable modem protocol (a.k.a DOCSIS®, see bibliography) 
or the European adaptation thereof (a.k.a Euro-DOCSIS®, see bibliography). The cable industry is in the rapid stages of 
deploying IP voice and other time critical multimedia services over these broadband cable television networks. 

The cable industry has recognized the urgent need to develop ETSI Technical Specifications aimed at developing 
interoperable interface specifications and mechanisms for the delivery of end to end advanced real time IP multimedia 
time critical services over bi-directional broadband cable networks. 

IPCablecom is a set of protocols and associated element functional requirements developed to deliver Quality of 
Service (QoS) enhanced secure IP multimedia time critical communications services using packetized data transmission 
technology to a consumer's home over the broadband cable television Hybrid Fibre/Coaxial (HFC) data network 
running the cable modem protocol. IPCablecom utilizes a network superstructure that overlays the two-way data-ready 
cable television network. While the initial service offerings in the IPCablecom product line are anticipated to be packet 
voice, the long-term project vision encompasses packet video and a large family of other packet-based services. 

The cable industry is a global market and therefore the ETSI standards are developed to align with standards either 
already developed or under development in other regions. The ETSI Specifications are consistent with the 
CableLabs/PacketCable™ set of specifications (see bibliography) as published by the SCTE (see bibliography). An 
agreement has been established between ETSI and SCTE in the US to ensure, where appropriate, that the release of 
PacketCable™ (see bibliography) and IPCablecom set of specifications are aligned and to avoid unnecessary 
duplication. The set of IPCablecom ETSI specifications also refers to ITU-T Study Group 9 draft and published 
recommendations relating to IP cable communication. 

The initial effort in IPCablecom has been on supporting analogue, POTS MTA terminals through IP AT V5.2 gateway 
interfaces (see TS 101 909-23, see bibliography) to support IP Voice (Telephony over IP) and other time critical 
multimedia services over these broadband networks. However, a need has been identified in TR 101 963 [8] (see 
clauses 5.3 and 9) to support also legacy ISDN terminal equipment in the wider European market. Consequently in 
order to support the development of broadband networks and equipment with support for legacy ISDN terminals, the 
key functions and features of these ISDN-capable MTAs need to be sufficiently defined. 
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The whole set of multi-part ETSI deliverables to which the present document belongs specify a cable communication 
Service for the delivery of IP multimedia time critical services over a HFC Broadband Cable Network to the consumers 
home cable telecom terminal. "IPCablecom" also refers to the ETSI TC AT working group program that shall define 
and develop these ETSI deliverables. 

NOTE: The present document may have impacts upon other deliverables of the ETSI multi-part IPCablecom 

series; such potential impacts are currently unknown and are for further study. Thus, a need may arise in 
the future to revise the present document accordingly. 
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Scope 



The present set of documents specifies IPCablecom, a set of protocols and associated element functional requirements. 
These have been developed to deliver Quality of Service (QoS), enhanced secure IP multimedia time critical 
communication services, using packetized data transmission technology to a consumer's home over a cable television 
Hybrid Fiber/Coaxial (HFC) data network. 

To facilitate maintenance and future enhancements to support other real-time multimedia services the TS 101 909 
document series consist of multi -parts as detailed in TS 101 909-1 [1]. 

The present document is part 24 providing a technical description of this architecture, and where appropriate, identify 
the portions of the IPCablecom specifications that apply to this architecture and their use. The embedded, 
ISDN-enabled MTA (iMTA) and its interfaces are described in the present document. The definition and interfaces of a 
standalone ISDN MTA (S-iMTA) are not described in the present document and remain as for further study. 

While the initial service offerings in the IPCablecom product line are anticipated to be packet voice and packet video, 
the long-term project vision encompasses a large family of packet-based services. This may require in the future, not 
only careful maintenance control, but also an extension of the present set of documents. 

The present document assumes familiarity with the IPCablecom architecture, specifically with DQoS, security and call 
signalling. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in RFC 3057bis [29] and the following apply: 

(IU A) -Application Server (AS): logical entity serving a specific application instance 

NOTE: An example of an Application Server (AS) is a CMS handling ITU-T Recommendation Q.931 [21] and 
call processing for D channels. Practically speaking, an AS is modelled at the iMTA as an ordered list of 
one or more related Application Server Processes (e.g. primary, secondary, tertiary); see also 
RFC 3057bis [29]. RFC 3057bis [29] uses the term AS synonymously with an instance of CMS. 

(IU A) -Application Server Process (ASP): process instance of an Application Server 

NOTE: Examples of Application Server Processes are primary or backup MGC instances; see also 
RFC 3057bis [29]. 

(SCTP)-association: association refers to a SCTP association 

NOTE: The association will provide the transport for the delivery of Q.921-User protocol data units and IUA 
adaptation layer peer messages; see also RFC 3057bis [29]. 

backhaul: iMTA terminates the lower layers of an SCN protocol and backhauls the upper layer(s) to MGC for call 
processing 

NOTE: For the purposes of the present document the iMTA terminates ITU-T Recommendation Q.921 [20] and 
backhauls ITU-T recommendation Q.931 [21] to MGC; see also RFC 3057bis [29]. 

Basic Rate Access (BRA): ISDN user-network access arrangement that corresponds to the interface structures 
composed of two B-channels and one D-channel 

NOTE: The bit rate of the D-channel for this type of access is 16 kbit/s (ITU-T Recommendation 1.430). 

B-channel: this function provides for the bi-directional transmission of independent B-channel signals each having a bit 
rate of 64 kbit/s 

cable modem: layer two termination device that terminates the customer end of the J.l 12 connection 
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Customer Premises Equipment (CPE): in the scope of TS 101 909-24 understood being an ISDN terminal as an 
instantiation of Telecommunications Terminal Equipment (TTE) 

D-channel: this function provides for the bi-directional transmission of one D-channel signal at a bit rate of 16 kbit/s 
for basic rate 

endpoint: Terminal, Gateway or MCU 

fail-over: capability to re-route signalling traffic as required between related ASPs in the event of failure or 
unavailability of the currently used ASP (e.g. from primary MGC to back-up MGC) 

NOTE: Fail-over also applies upon the return to service of a previously unavailable process; see also 
RFC 3057bis [29]. 

Flow [IP Flow]: unidirectional sequence of packets identified by ISO Layer 3 and Layer 4 header information 

NOTE: This information includes source/destination IP addresses, source/destination port numbers, protocol ID. 
Multiple multimedia streams may be carried in a single IP Flow. 

Flow [J.112Flow]: unidirectional sequence of packets associated with a SID (Service Identifier) and a QoS. Multiple 
multimedia streams may be carried in a single J.l 12 Flow. 

gateway: devices bridging between the IPCablecom IP Voice Communication world and other communication networks 
(e.g. the PSTN) 

NOTE: Examples are the Media Gateway which provides the bearer circuit interfaces to the PSTN and transcodes 
the media stream, and the Signalling Gateway which sends and receives circuit switched network 
signalling to the edge of the IPCablecom network. 

IPCablecom: ETSI deliverables including an architecture and a series of specifications that enable the delivery of real 
time services (such as telephony) over the cable television networks using cable modems 

(IUA)-Interface: for the purposes of TS 101 909-24 an IUA-interface supports the relevant ISDN signalling channel. 

NOTE: This signalling channel may be a 16 kbps D channel for an ISDN BRA. 

latency: time, expressed in quantity of symbols, taken for a signal element to pass through a device 

(IUA)-interface identifier: the IUA-interface Identifier identifies the physical interface at the iMTA for which the 
signalling messages are sent/received 

NOTE: The format of the Interface Identifier parameter can be text or integer, the values of which are assigned 

according to network operator policy. The values used are of local significance only, coordinated between 
the SG and ASP. Significance is not implied across SGs served by an AS; see also RFC 3057bis [29]. 

iMTA: this expression is used synonymous for Embedded MTA with ISDN access interface 

NOTE 1 : A system component that has integrated a Multimedia Terminal Adapter (MTA) providing an ISDN 
interface to the subscriber side. The CM offers an Ethernet interface towards the subscriber side to 
connect, data services, e.g. a PC. The Network interface consists of a cable modem interface towards the 
HFC network (CMTS). 

NOTE 2: The iMTA acts as a MGCP-controlled residential Media Gateway (MG) that backhauls DSS1 signalling 
via SCTP/IUA. Thus, the IUA signalling agent within the iMTA receives/sends SCN native signalling at 
the edge of the IP network. The IUA signalling function of an iMTA relays ITU-T Recommendation 
Q.931 [21] signalling. The SG function may also be co-resident with the MG function to process SCN 
signalling associated with line or trunk terminations controlled by the MG (e.g. signalling backhaul). 

ISDN: Integrated Services Digital Network that provides or supports a range of different telecommunications services 
and provides digital connections between user-network interfaces 

proxy: facility that indirectly provides some service or acts as a representative in delivering information there by 
eliminating a host from having to support the services themselves 
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Q.921-user: any protocol normally using the services of the ISDN Q.921 (e.g. ITU-T Recommendation Q.931 [21]) 

NOTE: See RFC 3057bis [29]. 

(SCTP)-stream: refers to an SCTP stream 

NOTE: A uni-directional logical channel established from one SCTP endpoint to another associated SCTP 
endpoint, within which all user messages are delivered in-sequence except for those submitted to the 
un-ordered delivery service. See also RFC 3057bis [29]. 

trunk: analogue or digital connection from a circuit switch which carries user media content and may carry voice 
signalling (MF, R2, etc.) 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AC Alternating Current 

AS Application Server (see IUA-AS) 

ASP Application Server Process (see IUA-ASP) 

BA Basic vote Access 

BRA Basic Rate Access (used synonymously as BRI) 

BRI Basic Rate Interface 

CA Call Agent 

CM Cable Modem 

CMS Call Management Server 

CMTS Cable Modem Termination System (used synonymously also as AN) 

CPE Customer Premises Equipment (used synonymously as TTE) 

DHCP Dynamic Host Configuration Protocol 

DNS Domain Name System 

DOCSIS™ Data-Over-Cable Service Interface Specifications 

DQoS Dynamic Quality of Service 

DSS1 Digital Subscriber Signalling No. 1 (UNI Signalling) 

DTMF Dual Tone Multi Frequency 

eMTA Embedded MTA 

HDLC High-level Data Link Control 

HFC Hybrid Fiber/Coaxial 

HW Hardware 

IETF Internet Engineering Task Force 

iMTA ISDN-capable embedded MTA 

IP Internet Protocol 

IPAT-LCS Internet Protocol Access Terminal - Line Control Signalling 

IPR Intellectual Property Rights 

IPSEC Internet Protocol Security 

ISDN Integrated Services Digital Network 

ITU International Telecommunications Union 

IUA ISDN User Adaptation 

IUA-AS IUA Application Server (CMS) 

IUA-ASP IUA AS Process 

KDC Key Distribution Center 

L3 ISDN Layer 3 

LE Local Exchange 

MG Media Gateway 

MGC Media Gateway Controller 

MGCP Media Gateway Control Protocol 

MIB Management Information Base 

MTA Multimedia Terminal Adapter 

NCS Network Control Signalling 

NIF Nodal Interworking Function 

NT Network Termination 

NTE Network Terminating Equipment 

NTFY Notify (see MGCP) 
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OSS Operational Support System 

PHY PHYsical Layer 

PKINIT Public-Key INITial authentication 

PL-EV Primary Line EVent 

POTS Plain Old Telephone Service 

PRA Primary Rate Access (used synonymously as PRI) 

PRI Primary Rate Interface 

PSTN Public Switched Telephone Network 

ptmp Point-to-Multipoint 

ptp Point-to-Point 

QoS Quality of Service 

REQ REQuest 

RFC Request for Comment 

RKS Record Keeping Server 

RQNT Notification Request (see MGCP) 

RTCP Realtime Transport Control Protocol 

RTP Realtime Transport Protocol 

SAPI Service Access Point Identifier 

SCN Switched Circuit Network 

SCTE Society of Cable Telecommunications Engineers 

SCTP Stream Control Transmission Protocol 

SDP Session Description Protocol 

SG Signalling Gateway 

S-iMTA Standalone ISDN-capable MTA 

SNMP Simple Network Management Protocol 

SW Software 

TE Terminal Equipment (see also CPE, TTE) 

TEI Terminal Endpoint Identifier 

TFTP Trivial File Transfer Protocol 

TGT Ticket Granting Ticket 

TTE Telecommunications Terminal Equipment (used synonymously as CPE and TE) 

UDP User Datagram Protocol 

UNI User-Network Interface 

USB Universal Serial Bus 

USM User-based Security Model 

VACM View-based Access Control Model 

WLAN Wireless Local Area Network 



Conventions 



If the present document is implemented, the key words "MUST" and "SHALL" as well as "REQUIRED" are to be 
interpreted as indicating a mandatory aspect of the present document. 



The key words indicating a certain level of significance of a particular requirements that are used throughout the present 
document are summarized in the table below: 



This word or the adjective "REQUIRED" means that the item is an absolute 
requirement of the present document. 



'MUST" 



'MUST NOT" 



This phrase means that the item is an absolute prohibition of the present 
document. 



'SHOULD" 



This word or the adjective "RECOMMENDED" means that there may exist valid 
reasons in particular circumstances to ignore this item, but the full implications 
should be understood and the case carefully weighed before choosing a different 
course. 



'SHOULD NOT" 



This phrase means that there may exist valid reasons in particular circumstances 
when the listed behaviour is acceptable or event useful, but the full implications 
should be understood and the case carefully weighted before implementing any 
behaviour described with this label. 



'MAY" 



This word or the adjective "OPTIONAL" means that this item is truly optional. One 
vendor may choose to include the item because a particular marketplace requires 
it or because it enhances the product, for example; another vendor may omit the 
same item. 
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System architecture 



The DSS 1 signalling of ISDN Subscribers is transported to the CMS via the backhaul mechanism of SCTP and IUA. 
The iMTA is treated like a residential media gateway where the bearer is controlled via MGCP/NCS. 

The iMTA specified in the present document supports the following ISDN services and applications: 

• circuit-mode 64 kbit/s unrestricted; 

• circuit-mode 3,1 kHz audio; 

• circuit-mode speech; 

• telephony 3,1 kHz; 

• telephony 7 kHz; 

• facsimile group 4 class 1; 

• facsimile group 3. 

The iMTA does not support any of the following ISDN services and applications: 

• packet-mode (X.31 base B) B- and D-channel; 

• teletex; 

• syntax-based videotex; 

• videotelephony; 

• primary Rate Access/Interface (PRI/PRA). 
The supported interface types are: 

• basic Rate Interface (BRI): 

Point-to-Point (ptp); 
Point- to-Multipoint (ptmp). 
Figure 1 shows the network architecture for an iMTA. 




Media 
Gateway 

(MG) 



Media 
Gateway 
Controller 

(MGC) 



CMS 



ISDN 

< ► 



SCTP/IUA+MGCP/NCS 
for ISDN call and bearer control 



Figure 1 : Network architecture for iMTA 
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5.1 



User interfaces 



The iMTA MUST offer ISDN as user side interface for voice service: 
• ISDN BA ptp and ptmp, DSS 1 signalling. 



5.2 



Network interfaces 



Towards the network side a cable modem interface (see ES 201 488-1 [10], ES 201 488-2 [1 1] and ES 201 488-3 [12]) 
or ES 202 488-1 [13], ES 202 488-2 [14] and ES 202 488-3 [16]) MUST be provided: 

• Cable modem with QoS support. 

5.3 Call control interfaces 

For ISDN the iMTA MUST provide SCTP (IUA (DSS.l)) as network call control interface: 

• SCTP (IUA (DSS 1)); 

• NCS deploying MGCP, DTMF, RTP; 

• maintenance functions MUST be controlled via MGCP (with AuditEndpoint and RestartlnProgress) 
commands. 

5.4 Management and provisioning interfaces 

An iMTA MUST provide DHCP (RFC 2131 [24], RFC 3495 [39]), TFTP (RFC 1350 [22]), DNS (RFC 1591 [23], 
RFC 3396 [31]), SNMPv3 and SYSLOG (RFC 3164 [30]) for the purpose of management and provisioning 
(see TS 101 909-6 [5]). 

The iMTA MUST deploy SNMPv3 (see RFC 3417 [37], RFC 3412 [34] and RFC 3414 [35]). A more detailed 
introduction to the current SNMP Management Framework can be found in RFC 3410 [32], an overall architecture is 
described in RFC 341 1 [33]. User-based Security Model (USM) RFC 3414 [35] and View-based Access Control 
Model (VACM) (RFC 3415 [36]) are supported to allow the cable operator to implement management policy for access 
to specified MIBs. The concept of management views was introduced with SNMPv3, and is defined in RFC 3410 [32] 
through RFC 3415 [36] and RFC 2576 [26]. It is a method for specifying what user(s) is/are allowed to access which 
MIB object(s). View-based Access Control Model (VACM) MUST be employed as defined by RFC 3415 [36]. 



5.5 



Protocol interfaces 



The Q.921 layer from the terminal equipment is terminated in the iMTA and converted to SCTP (IUA (DSS.l)), see 
figure 2. The ITU-T Recommendation Q.931 [21] protocol is relayed transparently through the iMTA. The bearer 
traffic is controlled via MGCP/NCS and transported in RTP sessions. 
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Figure 2: iMTA protocol stack overview 

The iMTA MUST offer ISDN as user side interface for voice services ISDN. The iMTA MUST support the transport of 
voice and data traffic in different Service Classes (see ES 202 488-2 [14]). 

For ISDN the iMTA MUST provide as network call control interface SCTP (IUA (DSS.l)). The maintenance control is 
performed via MGCP/NCS. 

5.6 HDLC/Q.921 interface 

The iMTA terminates the Q.921 layer and converts it into SCTP (IUA) towards the CMS. The iMTA MUST maintain 
the status of the SAPI/TEI; and optionally the CMS MAY maintain that status. For this reason it MUST be possible to 
configure the ISDN layer 2 service in the iMTA: 

• Point-to-Point/Point-to-Multipoint scenario; 

• permanent/non-permanent active layer 2; 

• timer value (TL2out) for periodically layer 2 re-establishment in case of permanent layer 2, (between 4 s and 
60 s, default is 7 s); 

• TEI Management procedures: 

For point-to-multipoint and non-permanent layer 2 application, the iMTA MUST be able to dynamically 
assign the TEI values in the range of 64 to 126. 

In the case of point-to-point and permanent layer 2 application the iMTA MUST be able to accept a 
pre-assigned TEI value in the range of to 63 from an ISDN terminal. 

The iMTA MUST ignore pre-assigned TEI value received from ISDN Terminal for Point-to-Multipoint 
line. 



5.7 



L3 ISDN interface 



TR 101 973-3 [9] describes the features and functionality including some flow scenarios of an ISDN terminal in the 
context of an IPCablecom environment. An iMTA as a broadband NTE backhauls any ISDN layer 3 signalling (see 
ITU-T Recommendation Q.931 [21]) through IUA over SCTP transport towards the CA of the CMS where the call 
control function is located. 
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6 System components 

6.1 Embedded ISDN MTA (iMTA) 

An embedded MTA (eMTA) is a hardware device that incorporates a cable modem (see ES 201 488-1 [10], 
ES 201 488-2 [1 1] and ES 201 488-3 [12] or ES 202 488-1 [13], ES 202 488-2 [14] and ES 202 488-3 [16]) as well as 
an IPCablecom multi-media terminal adapter component. Following this, the iMTA is an eMTA that has two logical 
parts, which are physically combined into one device (see note): a Cable Modem (CM), and an ISDN Multi-media 
Terminal Adapter (MTA). Every home using IPCablecom services has at least one such device. On the subscriber side, 
it supports ISDN, and optionally includes a local lOBaseT or 100BaseT port for high-speed data access. On the network 
side it supports the IPCablecom/cable modem/HFC network requirements. 

The cable modem is a modulator that provides data transmission over the cable network using the cable modem 
protocol (see ES 201 488-1 [10], ES 201 488-2 [11] and ES 201 488-3 [12] or ES 202 488-1 [13], ES 202 488-2 [14] 
and ES 202 488-3 [16]). In IPCablecom, the CM plays a key role in handling the media stream and provides services 
such as classification of traffic into service flows, rate shaping and prioritized queuing. 

The iMTA is an IPCablecom client device that contains a subscriber side interface to the subscriber's ISDN terminal 
(e.g. ISDN telephone) and a network side voice and signalling interface to elements in the network. iMTA basically 
handles the two-way translation of voice to IP packets, and two-way ISDN to IP based signalling conversion. iMTA 
provides codecs and all signalling and encapsulation functions required for media transport and call signalling. 
IPCablecom iMTAs are REQUIRED to support the Network Call Signalling (NCS) protocol. 

The iMTA MAY optionally provide a high speed "data port" that MAY be of a type IEEE 802.3 Ethernet 
(10/100 baseT, RJ-45) and/or USB or other access technology (IEEE 802.11 WLAN, Bluetooth etc). The choice of 
which type is offered in a given iMTA is market driven. The present document does not cover the high speed "data 
ports". 

NOTE: Presence of a high-speed "data port" raises the need for QoS assurance mechanisms 
(see clause 7.3 "DQoS"). 

Figure 3 gives an overview of the typical functional blocks of the iMTA. 
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Figure 3: iMTA functional blocks overview 

NOTE: The present document does only address an embedded iMTA, a standalone iMTA (S-iMTA) is out of 
scope of the present document. 
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6.2 Fail-over, robustness and reliability 

iMTA users would expect a similar availability in an IPCablecom environment than they are used to from the 
circuit-switched PSTN/ISDN. For this reason iMTA has to address appropriate measures to provide sufficient 
robustness and reliability. To meet the ISDN signalling reliability and performance requirements for carrier-grade IP 
networks, network operators SHOULD ensure that there is no single point of failure of their CMS. 

The following architecture enables cable service operators to deploy multiple redundant CMS systems with active and 
standby call agents to meet the required reliability needs. There MUST at least be one active call agent for 
MGCP/SCTP/IUA communication and one or more standby call agents. The standby call agents are maintained only for 
backup purposes and will come into play just when the active call agent failed. 

At startup, the iMTA knows the set of call agents (e.g. through configuration or network management). Using DNS, the 
iMTA is able to resolve the configured symbolic names of the call agents. 

In case the iMTA cannot reach one call agent, a switchover procedure to another standby call agent will be executed. 
The iMTA will then send its messages to the new active call agent. 

Figure 4 shows an example with two redundant CMS each on different hosts. Each CMS features an MGC that has 
established a MGCP/SCTP/IUA link towards the iMTA. One of those links becomes active while the other one is kept 
for backup reasons. 

The CMS on both hosts MAY share their state (e.g. by shared memories) or MAY communicate state information 
through some protocol means; such means are outside the scope of the present document. For example, such 
communication means are necessary to transfer context, call and security state from one system to another in case of 
fail-over. 
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Figure 4: Redundant call agents 



6.2.1 



MGCP 



The iMTA MUST adhere to the MGCP specification as given in RFC 3435 [38] and RFC 3661 [41]. RFC 3435 [38] 
takes precedence in case of conflicts with NCS part 4. 

It is recommended that the iMTA follows the guidelines and procedures RFC 3435 [38] for handling failover, 
robustness and reliability. In particular, see section 4 "States, Failover and Race Conditions" and subsections 4.1 
"Failover Assumptions and Highlights" and 4.4.6 "Fighting the Restart Avalanche". 
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6.2.2 SCTP 



If ISDN ports are located on the iMTA the active and the standby call agent initiate an SCTP association with the iMTA 
and setup their IUA connection with "ASP Up"/" ASP Up Ack" message. Only the active call agent sends an 
"ASP Active" message to the iMTA to allow the exchange of IUA messages; see annex A: 

• Both call agents establish an own SCTP association with the iMTA. In the associations for each D-channel a 
separate SCTP stream is set up; i.e. for an iMTA with 4 S ports, 4 SCTP streams per SCTP association are 
required. The number of streams cannot be changed during the lifetime of an association and MUST be 
configurable. 

• After the SCTP association is setup with SCTP streams in both directions, IUA communication between iMTA 
and both call agents starts: Both call agents announce themselves with "ASP Up" messages and expect 
acknowledgements from their peers on the iMTA. In the header of the outgoing messages the call agents use 
the IP- Address of the iMTA and the "well-known" destination SCTP port address 9900 together with the own 
IP-Address and any free unused SCTP port address. 

• When the active call agent receives the "ASP Up Ack" message from the iMTA it announces itself as the 
active partner with an "ASP Active" message. With the reception of the "ASP Active Ack" message the IUA is 
now ready to transport ITU-T Recommendation Q.931 [21] primitives between call agent and iMTA. 

• After the SCTP Association has been established both iMTA and call agent (both active and standby) start 
supervising the association status by sending periodic heartbeat messages to each other. 

6.2.3 Q.921 

The iMTA terminates the Q.921 layer and maps it into IUA. Depending on the layer 2 status configuration the iMTA 
MUST perform the following actions: 

• Permanent layer 2: The iMTA is responsible for layer 2 establishment. Each time the layer 2 towards the 
terminal equipment breaks down the iMTA has to perform the following actions: 

1) Layer 2 outage: 

■ try to re-establish layer 2 connection to terminal equipment and send IUA establish indication to 
call agent in case of successful layer 2 re-establishment; 

■ send IUA Release indication in case the layer 2 can not be built up successfully after T200 elapsed 
N200 times (see ITU-T Recommendation Q.921 [20]). The iMTA MUST continue periodically 
(interval TL2out, configurable timer) to re-establish the layer 2 towards the terminal and inform the 
call agent after successful re-establishment with IUA Establish indication. 

2) Switch-over of SCTP association: after the outage of the active SCTP association and the switch-over to 
the standby SCTP association the iMTA MUST check whether the layer 2 towards the terminal 
equipment is still active, if: 

■ Yes: send an IUA Establish indication on the new active SCTP association. 

■ No: try to re-establish the layer 2 and act as described above under 1 . 

• Non-permanent layer 2: Normally the iMTA indicates a layer 2 establishment (initiated by the terminal 
equipment during call setup) to the CMS. However, also the CMS may request a layer 2 establishment. If the 
iMTA receives an IUA Establish request message from the call agent it MUST check whether the layer 2 
towards the terminal equipment is still active. If: 

Yes: send an IUA Establish confirmation to the call agent. 

No: try to re-establish the layer 2 towards the terminal and inform the call agent after the layer 2 is 

re-established with IUA Establish confirmation. In case the layer 2 can no longer be activated the 
iMTA MUST inform the call agent after T200 elapsed N200 times (see ITU-T Recommendation 
Q.921 [20]) with IUA Release indication message. 
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The iMTA assigns the TEI values. The iMTA MUST maintain the status of the TEIs, and CMS MAY maintain the 
status of the TEIs. The status of the TEIs MAY be queried and/or indicated (but MUST NOT be changed) via the IUA 
management messages; see section 3.3.3.3 "TEI Status Messages" and section 3.3.3.4 "TEI Query Messages" of 
RFC 3057bis [29]. 



7 iMTA power, physical and electrical characteristics 

This clause provides information on the physical and electrical characteristics of an iMTA including aspects of power. 

The iMTA is a device that is situated in two distinct networks: HFC and ISDN. As such the iMTA MUST comply with 
the physical and electrical characteristics of either network type: 

a) The ISDN side of the iMTA acts as an ISDN Network Termination (NT) towards the CPE (TE). For this case, 
the iMTA MUST comply with the Basic User-Network Interface (UNI) Layerl specification 

(see EN 300 012-1 [15]). In particular, clause 9 of EN 300 012-1 [15] yields the electrical characteristics, 
clause 10 of EN 300 012-1 [15] addresses power feeding and clause 11 of EN 300 012-1 [15] specifies the 
interface connector contacts. The iMTA does not support ISDN power feeding towards the TE 
(see EN 300 012-1 [15] clauses 6.1.7, 6.3.1 and 10) in the event of failure. 

b) The HFC side of the iMTA acts as a cable modem. For this case, the iMTA MUST comply with the 
ES 201 488-2 [1 1] or with the ES 202 488-2 [14] physical and electrical characteristics. 

The iMTA MAY have two sources of input power; the HFC Network and the local premises AC Utility. 

7.1 HFC network powering 

The HFC network is typically powered by distributed power nodes. 

Powering of the iMTA by the HFC Network is for further study. In all the cases the powering MUST comply with the 
appropriate harmonized safety standards or appropriate national safety standards. 

7.2 Premises powering 

This is the method of providing local AC utility power directly to the iMTA from a receptacle at the premises. 

7.2.1 Mechanical interface 

The vendor MUST supply an appropriate AC mains line cord compliant with the appropriate harmonized safety 
standards or appropriate national safety standards. 

7.2.2 Input voltage 

The device SHOULD operate at the normal AC Supply voltage tolerance ranges. 

7.2.3 Telephony service availability considerations 

The delivery of a highly available Telephony service to the users is directly impacted by the reliability of the local AC 
utility provider. Some administrations and/or network operators require to provide alternate power to bridge across AC 
utility power loss. 

The most common method of providing alternate power for the AC utility over relatively short periods of time is to 
provide a battery backup system. 

The following requirements assume a battery backup system is employed. These requirements are not intended to 
dictate any specific implementation architecture or method as long as the functional goal of the backup system is 
achieved. 
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The implementation of a battery backup system is NOT REQUIRED by the present document but MAY be subject to 
national regulation. 

7.2.3.1 Up power interruptions 

7.2.3.1 . 1 AC utility to back up supply 

The iMTA transition from AC utility power (power loss) to a back up power source (battery) MUST maintain all 
established voice and data connections. 

7.2.3.1 .2 Back up supply to AC utility 

The iMTA transition from a back up power source (battery) to the AC utility power (power restoration) MUST maintain 
all established voice and data connections. 

7.2.3.2 Automatic operation 

The switching from AC utility power to battery back up MUST operate without service personnel or user intervention. 

The switching from battery back up to AC utility power MUST operate without service personnel or user intervention. 

If the battery is capable of being re-charged (e.g. secondary cell type), the battery charger operation (e.g. starting battery 
charge, ending battery charge, etc.) MUST operate without service personnel or user intervention. 

7.2.3.3 Operation without battery 

The iMTA MUST maintain all connection services if the battery is removed for service or replacement. 

The iMTA MUST maintain all connection services if the battery is determined as requiring replacement, see 
clause 6.2.3.7.2.2. 

7.2.3.4 Service limitations 

During operation on backup power, data connections MAY optionally be disabled. 
Upon return of AC utility power, data connections MUST be enabled. 

7.2.3.5 Battery run time 

Battery run time is dependent on the iMTA design, the back up system efficiency and the size and type of back up 
battery. These parameters represent various trade off considerations to meet specific run time goals per local 
administration requirements and product costs. 

It is not possible to define any specific run times across all administrations therefore; the present document leaves 
specific run time goals to national regulation. 

The vendor MUST specify the expected run time of the iMTA assuming a battery in good condition with a full charge 
for a representative sample of modes of iMTA operation in accordance with national regulations or based on operators 
specification where there is no national regulation. Since vendor equipment MAY be configured with different types 
and quantities of interfaces, it is the vendor obligation to provide the appropriate combinations of port states and modes 
as appropriate for the equipment being offered. 

The minimum modes that MUST be specified: 

1) Idle run time - the iMTA is supporting the required protocol overhead, one telephony port is provisioned, all 
other telephone and data ports are disabled (not provisioned) and there is no active telephony connection on 
the provisioned telephony port. At the end of the Idle Run Time the iMTA MUST still originate a single, 3 min 
telephony connection without any other connection activity. 
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2) Provisioned Run Time - The iMTA is supporting the required protocol overhead, all telephony and data ports 
are provisioned, and there are no active telephony or data connections. At the end of the Provisioned Run Time 
the iMTA MUST still originate a single, 3 min Telephony Connection without any other connection activity. 

3) Data Run Time - The iMTA is supporting protocol overhead, all telephony ports are disabled (not 
provisioned), all data ports are provisioned, and with a full data rate connection active, unless disabled per 
clause 6.2.3.4.5. 

4) Talk Run Time - the time the iMTA can support the required protocol overhead, all telephony and data ports 
are provisioned, and there is one continuous telephony connection and no data connections. 

5) Full Load Run Time - the time the iMTA can support the required protocol overhead with all of the Telephony 
connections active and a full rate data connection, unless disabled per clause 6.2.3.4. 

7.2.3.6 Battery recharge time 

If the battery is capable of being re-charged (e.g. secondary cell type), the vendor MUST specify the time to recharge 
the back up battery to at least 80 % of its capacity after the return of the AC utility power assuming the battery was fully 
discharged. 

7.2.3.7 Back up telemetry 

In order to maintain the high availability provided by the back up battery the iMTA MUST monitor various AC utility 
and battery states and report them to the OSS system so that the operator can replace aged or defective back up systems. 

7.2.3.7.1 Operations Support System (OSS) event reporting 

The iMTA MUST support the event and alarm reporting mechanism as defined in TS 101 909-22 [7]. This mechanism 
is used to configure the line events on the iMTA. This mechanism is also used to report the Line Events in a local log or 
to send these events to an OSS back office system via SNMP or S YSLOG. 

All Line Events MUST be defined as a matched pair of "set" and "cleared" events. Eight Line Events are programmable 
events and therefore MAY be redefined to support a meaning other than the battery-related meanings defined in the 
present document. If these Line Events are redefined, then the definition of the new meaning and any coordination 
between systems to support this new meaning is out of the scope of IPCablecom. 

The "set" and "clear" events for the four alarm signals are defined below. 

7.2.3.7.2 Telemetry signals 

7.2.3.7.2.1 Telemetry signal 1 - AC fail 

The active alarm state of this signal indicates an "AC Fail" condition, which means the Back Up Supply, has detected a 
failure of the utility AC power and is operating off its battery. 

The inactive alarm state of this signal indicates an "AC Restored" condition that means the Back Up Supply has 
detected the presence of utility AC power and is no longer operating off its battery: 

• PL-EV-1: active alarm state of telemetry signal 1; default meaning "AC Fail" and default severity MINOR. 

• PL-EV-2: inactive alarm state of telemetry signal 1, default meaning "AC Restored"; PL-EV-2 always clears 
PL-EV-1. 

7.2.3.7.2.2 Telemetry Signal 2 - Replace Battery 

The active alarm state of this signal indicates a "Replace Battery" condition which means the Back Up Supply, via 
internal test mechanisms outside the scope of the present document, has determined that the battery can no longer 
maintain a charge sufficient enough to provide the designed amount of battery run time and thus is failing and MUST 
be replaced with a new battery. 



ETSI 



22 ETSI TS 1 01 909-24 V1.1.1 (2004-05) 

The inactive alarm state of this signal indicates a "Battery Good" condition: 

• PL-EV-3: active alarm state of telemetry signal 2; default meaning "Replace Battery" and default severity 
MINOR. 

• PL-EV-4: inactive alarm state of telemetry signal 2; default meaning "Battery Good"; PL-EV-4 always clears 
PL-EV-3. 

7.2.3.7.2.3 Telemetry Signal 3 - Battery Missing 

The active alarm state of this signal indicates a "Battery Missing" condition, which means the Back Up Supply has 
detected that a battery is not present and a battery MUST be installed to support the Back Up Supply. 

The inactive alarm state of this signal indicates a "Battery Present" condition: 

• PL-EV-5: active alarm state of telemetry signal 3; default meaning "Battery Missing" and default severity 
MINOR. 

• PL-EV-6: inactive alarm state of telemetry signal 3; default meaning "Battery Present"; PL-EV-6 always clears 
PL-EV-5. 

7.2.3.7.2.4 Telemetry Signal 4 - Battery Low 

The active alarm state of this signal indicates a "Battery Low" condition. This condition is defined to mean that battery 
has sufficiently discharged (e.g. approximately 75 % to 80 % discharged) to the point where a power source can only be 
maintained for a short while longer. 

The inactive alarm state of this signal indicates a "Battery Not Low" condition. This condition means that the battery 
has a charge capacity above the "battery low" threshold (e.g. at least 20 % to 25 % of full capacity): 

• PL-EV-7: active alarm state of telemetry signal 4; default meaning "Battery Low" and default severity 
MINOR. 

• PL-EV-8: inactive alarm state of telemetry signal 4; default meaning "Battery Not Low"; PL-EV-8 always 
clears PL-EV-7. 



8 System interfaces 



Protocol specifications have been or are currently being defined for most component interfaces within the IPCablecom 
architecture. An overview of these component interfaces is provided in the IPCablecom architecture framework 
Technical Report (see TS 101 909-1 [1]). The individual IPCablecom protocol specifications SHOULD be consulted for 
complete requirements of each component interface. 

New interfaces pertaining to the support iMTA have been added to the IPCablecom architecture. These will be detailed 
in the following clauses. Existing IPCablecom interfaces are not always shown unless they are directly related to the 
iMTA. 

There are no event messages interfaces for iMTA. 

8.1 Physical and data link layer interfaces 

Table 1 summarizes the physical interfaces of an iMTA. 

The cable modem data link interfaces from the iMTA towards the HFC network MAY be ES 201 488-1 [10], 
ES 201 488-2 [1 1], ES 201 488-3 [12] or MAY be ES 202 488-1 [13], ES 202 488-2 [14] and ES 202 488-3 [16]. 

The iMTA MAY optionally provide a high speed "data port" that MAY be of a type IEEE 802.3 Ethernet 
(10/100 baseT, RJ-45) and/or USB or other access technology (IEEE 802.11.x WLAN, Bluetooth etc). The choice of 
which type is offered in a given iMTA is market driven. The present document does not cover the high speed "data 
ports". 
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Table 1 : Physical Interfaces 



COMPONENT INTERFACE 


PHYSICAL INTERFACE 


iMTA-to-HFC Network (AN) 


ES201 488-1 [10], ES201 488-2 [1 1] and ES 201 488-3 [12] or 
ES 202 488-1 [13], ES 202 488-2 [14] and ES 202 488-3 [16]) 


iMTA-to-CPE 


ISDN S 

(IEEE 802.3, USB, or other high-speed data port OPTIONAL) 


iMTA-to-CMS/MGC 


no direct physical interface 



8.2 Call signalling interfaces 



Figure 5 identifies the call signalling interfaces for an iMTA when used in an IPCablecom architecture; see also the 
interface description in table 2. Interface Pkt-cl 1 is a new IPCablecom interface specific to an iMTA between an iMTA 
and CMS. 
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Figure 5: Call signalling interfaces 
Table 2: Call signalling interfaces 



Component Interface 


IPCablecom 

Functional 

Components 


Description 


Pkt-c1 


iMTA-MGC 


Call signalling messages for ISDN bearer and maintenance 
control exchanged between the MTA and MGC using the 
NCS protocol, which is profile of MGCP. 


Pkt-c11 (new) 


iMTA-CMS 


ISDN Call control signalling messages exchanged between 
the MTA and the CMS using the IUA over SCTP protocol. 


ITU-T Recommendation Q.931 [21] 


CPE-CMS 


ISDN User-network signalling. 



8.2.1 SCTP interface 

The Stream Control Transmission Protocol (SCTP) is a new IP transport protocol, existing at an equivalent level with 
UDP and TCP, which currently provide transport layer functions to many Internet applications. SCTP has been 
approved by the IETF as a Proposed Standard, and is specified in RFC 2960 [28]. 

Like TCP, SCTP provides a reliable transport service, ensuring that data is transported across the network without error 
and in sequence. Like TCP, SCTP is a session-oriented mechanism, meaning that a relationship is created between the 
endpoints of an SCTP association prior to data being transmitted, and this relationship is maintained until all data 
transmission has been successfully completed. 

The SCTP Implementors Guide (see bibliography) captures technical corrections to RFC 2960 [28] and MUST take 
precedence over RFC 2960 [28]. 

SCTP is used for transport of IUA messages from the iMTA to the CMS. 

The iMTA MUST support the SCTP protocol according RFC 2960 [28] and the IUA protocol according 
RFC 3057bis [29]. 
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For ISDN subscribers the call control signalling MUST be performed via SCTP (IUA (DSS.l)) signalling backhaul. 
Within the SCTP (IUA) service some data (e.g. retransmission timers, etc.) need to be configured. 

8.2.2 IUA interface 

IUA (see RFC 3057bis [29]) defines a protocol for backhauling of ISDN Q.921-user messages (e.g. ITU-T 
Recommendation Q.931 [21] messages) over IP using the Stream Control Protocol (SCTP). IUA provides the capability 
to transport ITU-T Recommendations Q.921/Q.931 boundary primitives. 

This IUA protocol MUST be used between the iMTA and the CMS for ISDN call control signalling. It is assumed that 
the iMTA receives ISDN signalling over a standard ISDN user interface. IUA supports as well point-to-point as 
point-to-multipoint communication mode. 

The iMTA has to terminate the ITU-T Recommendation Q.921 [20] protocol towards the ISDN interface and convert 
the received Q.921 -user messages into IUA message format towards CMS. 

Between iMTA and CMS one SCTP association MUST be established. The SCTP association MUST be established 
with iMTA start-up. The CMS MUST act as a SCTP client and MUST establish the SCTP associations to the iMTAs. 
Inside this SCTP association a number of SCTP streams, e.g. one SCTP stream per D-channel MUST be assigned. The 
number of SCTP streams MUST be configurable. The SCTP streams are unidirectional channels; i.e. in the iMTA per 
ISDN port one outbound SCTP stream is assigned and one inbound stream MUST be accepted. 

In the iMTA a further SCTP stream for maintenance and status information exchange MUST be assigned. 

The IUA message header contains an interface identifier field. For a given interface the iMTA MUST be able to 
identify the associated signalling channel. 

The iMTA MUST perform a dynamic assignment of D-channel messages onto a physical interface. For this reason the 
iMTA must maintain a map of the IUA interface identifier to a physical interface on the iMTA. The IUA interface 
identifier MUST correspond 1:1 to the iMTA BA port number, beginning with one (IID1 <-> BA1). 

If the IUA layer becomes inactive due to a CMS failure the iMTA MUST inform the Q.921 layer to e.g. perform some 
actions on ITU-T Recommendation Q.921 [20] basis: 

• IUA protocol functions on CMS: 

Each SCTP association is subdivided into several streams which represent the ports connected 
(i.e. D-channels). The SCTP streams are unidirectional channels. 

• IUA protocol functions on iMTA: 

On the iMTA the IUA receives ISDN signalling via a standard S interface. 

Between iMTA and CMS one SCTP association MUST be established. The SCTP association is 
established by the CMS. 

Inside this SCTP association one SCTP stream per D-channel is assigned. The SCTP streams are 
unidirectional channels, i.e. in the iMTA per ISDN port one outbound SCTP stream is assigned and one 
inbound stream MUST be accepted. In the iMTA a further SCTP stream for maintenance and status 
information exchange MUST be assigned (streamO). 

For a given interface the iMTA MUST be able to identify the associated signalling channel. The iMTA 
MUST perform a dynamic assignment of D-channel messages onto a physical interface. For this reason 
the IUA in the iMTA MUST maintain a map of the interface identifier to an association and stream 
represented by a physical interface on the iMTA. 

The TEI values are assigned in the iMTA. The iMTA has to maintain the status of the TEIs, and CMS 
MAY maintain the status of the TEIs. The status of the TEIs MAY be queried and/or indicated (but 
MUST NOT be changed) via the IUA management messages; see section 3.3.3.3 "TEI Status Messages" 
and section 3.3.3.4 "TEI Query Messages" of RFC 3057bis [29]. 
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8.2.3 MGCP interface 

The iMTA MUST adhere to the MGCP specification as given in RFC 3435 [38] and RFC 3661 [41]. RFC 3435 [38] 
takes precedence in case of conflicts with NCS part 4. Support of SDP (RFC 2327 [25]) is required by RFC 3435 [38] 
implicitly. 

8.2.3.1 ISDN access line endpoint identifiers/names 

Embedded clients MUST have at least one endpoint and MAY have more than one endpoints (e.g. one for each RJ1 1 
jack) associated with them, and each of the endpoints is identified by a separate local endpoint name. 
Embedded clients will support the following endpoint-type. 

Endpoints in iMTA clients MUST support the additional naming conventions specified in this clause: 

• Basic Access ISDN: The ISDN telephone is represented as an ISDN access line (ialn). This is basically the 
equivalent of an ISDN telephone line as known in the PSTN. 

• Endpoint names MUST comply with the format as defined by clause 6.1.1 of TS 101 909-4 [3]; see also 
RFC 2822 [27] section 3.4.1. 

In addition to the naming conventions specified above, local endpoint names for endpoints of type "ISDN access line" 
(ialn) for embedded clients MUST adhere to the following: 

• Local endpoint names contain at least one and, at most, three terms: 

Terml MUST be the term "ialn" or a wildcard character. It should be noted that the use of a wildcard 
character for terml could refer to any or all endpoint-types in the embedded client regardless of their 
type. Use of this feature is generally expected to be for administrative purposes, e.g. auditing or restart. 

Term2 MUST identify the ISDN type (BRA) and a logical number from one to the number of ISDN 
access lines supported by the embedded iMTA client in question. The number identifies a specific ISDN 
access line on the iMTA. Term2 MAY identify the username of some ISDN endpoint/port. 

Term3 MUST identify the specific B-Channel being logical number one or two in case of BRA. Term3 
MAY identify the ISDN port name as the local endpoint name of some ISDN endpoint. 

• If a local endpoint name is composed of only one term, that term will be terml . 

• If terml is not a wildcard character, the wildcard character dollar sign (referring to "any one") is then assumed 
for term2, i.e. "ialn" is equivalent to "ialn/$". 

• If terml is a wildcard character, the wildcard character asterisk (referring to "all") is then assumed for term2, 
i.e. " *" and "$" is equivalent to respectively " * / *" and " $ / *". 

EXAMPLES: 



ialn/BA8/Bl 


First B-channel for ISDN basic access line No. 8. 


ialn/BA46/* 


Any B-channel for ISDN basic access line No. 46. 


ialn/BA*/* 


Any B-channel for any ISDN basic access line. 


ialn/*/* 


Any B-channel for either ISDN BRA. 


ialn/username/Bl@home . de 


ISDN equipment of username on ISDN port B1 in the 
home.de domain. 


ialn /user name/* 


ISDN equipment of username on any ISDN port in any 
domain. 


* /* /* 


Any endpoint (regardless of endpoint-type) on the iMTA client 
in question. 


* 


Any endpoint (regardless of endpoint-type) on the iMTA client 
in question. 
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The provisioning/(auto)configuration process is responsible for obtaining and providing information about how many 
endpoints an embedded client has, as well as the endpoint-type of each endpoint. Although they are logically different, 
it should be noted that the endpoint-type can be derived from the local portion of the endpoint name. 

8.2.3.2 Tone/DTMF 

DTMF digit transport is controlled via MGCP, i.e. MGCP will request from the iMTA to activate or deactivate DTMF 
detection with MGCP RQNT messages. According to the current condition the iMTA shall either send DTMF digits via 
MGCP (e.g. the dialled digits) or transport them in the bearer channel inside the RTP stream. To guarantee a transparent 
transport of the DTMF digits and tones a non-compressing codec ITU-T Recommendation G.71 1 [17] is required. 
When a compressing codec, e.g. ITU-T Recommendation G.723 (see bibliography) is used for a connection, the 
transparent transport of DTMF digits is not guaranteed, therefore in this case the MGC request from iMTA to detect 
DTMF digits and signal them to the MGC via NTFY. The MGC sends then the digits with RQNT to the other side of 
the connection, where the corresponding tone must be applied. 

RFC 3660 [40] provides the specification of the DTMF package (see section 2.2 "DTMF Package"). 

8.3 QoS interfaces 

IPCablecom Dynamic QoS (DQoS) uses the call signalling information at the time that the call is made to dynamically 
authorize resources for the call. Dynamic QoS prevents various thefts of service attack types by integrating QoS 
messaging with other protocols and network elements. The network elements that are necessary for iMTA in an 
Dynamic QoS control Architecture are described in TS 101 909-5 [4]. 

8.4 Media interfaces 

iMTA deploys the same media interfaces as described in the IPCablecom architecture part 2 clause 6.2; 
see TS 101 909-2 [2]. 

8.5 Announcement service interfaces 

See TS 101 909-2 [2] clause 6.7 for announcement service interfaces. 

8.6 iMTA device provisioning interfaces 

See TS 101 909-2 [2] clause 6.3 for device provisioning interfaces. 



8.7 Security interfaces 



The present document inherits the same security interfaces as defined by the IPCablecom security architecture in 

TS 101 909-1 1 [6] as appropriate; any other security interfaces that are not directly related to the iMTA are not shown 

in figure 6. 
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Remote 
iMTA 



pkt-s3: RTP 
(Cipher + HMAC/ CMS-based KM) 

pkt-s4: RTCP 
(IPSec /CMS-based KM 




pkt-s17:Kerberos 
Issue Kerberos Tickets 



CO -- 
Q. 2 



pkt-s97:vDHCP 



pkt-s56^: DNS 




^DNS >> 
( SERVER ) 



f MG \ 



Figure 6: iMTA security interfaces 
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Table 3: iMTA security interfaces 



Component 
interface 


IPCablecom 

functional 

components 


Description 


pkt-sO 


iMTA - PS/OSS 


Immediately after the DHCP sequence, the iMTA performs 
Kerberos-based key management with the Provisioning Server to 
establish SNMPv3 keys. All SNMP messages are authenticated with 
privacy being optional. 


pkt-s1 


iMTA - TFTP 


iMTA Configuration file download. When the Provisioning Server sends 
an SNMP Set command to the iMTA, it includes both the configuration 
name and the hash of the file. Later, when the iMTA downloads the file, it 
authenticates the configuration file using the hash value. The 
configuration file may be optionally encrypted. 


pkt-s3 


iMTA -iMTA 
iMTA - MG 


RTP: End-to-end media packets between two iMTAs, or between iMTA 
and MG. RTP packets are encrypted directly with the chosen cipher. 
Message integrity is optionally provided by an HMAC MMH. Keys are 
randomly generated and exchanged by the two endpoints inside the 
signalling messages via the CMS. 


pkt-s4 


iMTA -iMTA 
iMTA - MG 


TCP: RTCP control protocol for RTP. Message integrity and encrypted 
by selected cipher. The RTCP keys are derived using the same secret 
negotiated during the RTP key management. No additional key 
management messages are needed or utilized. 


pkt-s5 


iMTA - CMS 


NCS: Message integrity and privacy via IPSec for the NCS and 
IUA/SCTP protocols Key management is with Kerberos with PKINIT 
(public key initial authentication) extension. 


pkt-s1 2 


iMTA - MSO KDC 


PKINIT: An AS-REQ message is sent to the KDC with public key 
cryptography used for authentication. The KDC verifies the certificate 
and issues either a service ticket or a Ticket Granting Ticket (TGT), 
depending on the contents of the AS Request. The AS Reply returned by 
the KDC contains a certificate chain and a digital signature that are used 
by the iMTA to authenticate this message. In the case that the KDC 
returns a TGT, the iMTA then sends a TGS Request to the KDC to which 
the KDC replies with a TGS Reply containing a service ticket. The TGS 
Request/Reply messages are authenticated using a symmetric key 
inside the TGT. 


pkt-s1 3 


iMTA - Tel KDC 


PKINIT: See pkt-s1 2 above. 


pkt-s96 


iMTA - DNS 


DNS: Used by the iMTA to obtain IP addresses for KDC and TFTP 
servers. Cryptographic methods are not specified on this interface for all 
IPCablecom architectures. Securing this interface is at the discretion of 
the system operator. 


pkt-s97 


iMTA - DHCP 


DHCP: used by the various network elements to obtain an IP address. 
Cryptographic methods are not specified on this interface for all 
IPCablecom architectures. Securing this interface is at the discretion of 
the system operator. 



NOTE: The present document does not define any particular security interface between the iMTA and the 

CPE on the ISDN link. Typically, those parts of under the security control of the user and do not need 
particular security measures. In those rare cases where very-high security needs are of concern, ISDN 
crypto boxes between iMTA and CPE may be deployed for that purpose. 



8.8 



IPAT-LCS interface 



The iMTA network architecture (see figure 1) is compliant with the Line Control Signalling (LCS) architecture as 
described in TS 101 909-23 (see bibliography). The Internet Protocol Access Terminal (IP AT) together with the Local 
Exchange (LE) provides the functionality of the MGC, MG, CMS and of SG, RKS and Announcement Server. 

The IP AT terminates the NCS/MGCP, SCTP and ITU-T Recommendations Q.921/Q.931/IUA signalling protocols 
to/from the iMTA. 



ETSI 



29 



ETSI TS 101 909-24 V1.1.1 (2004-05) 



Annex A (informative): 
Example message flows 



The following figures show example message flows for call setup between iMTAs including CMS/MGC for various 
scenarios and applications. The CMS/MGC is shown as two functionally separate entities, but omit any internal 
communication between MGC and CMS. 

NOTE: The message flow illustrate MGCP/NCS and ISDN call signalling, but omit any details on QoS/Cable 
Modem and other IPCablecom protocols. 

The messages are numbered sequentially, but some unrelated messages are not shown and gaps in the sequence 
numbers result. It is to be noted, that the message flows show a particular protocol instantiation, slightly different timing 
orderings may be observed in practice with a particular implementation. 

The MGCP messages show only the most important parameters (e.g. MGCP calllD field - when present - is shown as 
C: without given the actual value); but often omit any details; equally SCTP and IUA message are just indicated yet 
lack any further detail. The MGCP I: Connectionld is shown as a symbolic value rather than a numeric value. 



A.1 Example: Outgoing call ISDN, gateway B release 

Figures Al and A.2 illustrate a scenario where iMTA-A calls the B-side through a gateway. Thus, the present 
document's signalling occurs only between iMTA-A and MGC, CMS; the actual terminating endpoint beyond the 
gateway at the B-side is not shown. 

CMS Gateway 



Layer 2 
established 



l(SETUP) 



5) MGCP: CF CX EPID: ialri/BAIWBI 8 iMTA-A C: M :inactive Q: L: a:PCMA R: G/ft(N).Omt(N) X: 



I(ALERTING) 



1) SCTP: Q.921: Establish Jnd 



1) SCTP: SACK 



3) SCTP: Q.921 : Datajnd Q.931: SETUP 



1) SCTP: SACK 



6) M GCP: 200 OK I: cid 1 SDP: 



71 MGCP: RQNT EPID: itiln/BAIH/BI ® iMTA-A Q: R: G/fl(N),G/mt(N) L/dl X: 



8) SCTP: Q.921: Data_Req Q.931 



9) MGCP: 200 OK 



10) SCTP: SACK 



11) SCTP: Q.92 1 : Datajnd Q.93 1 : Information 



13) MGCP: RQNT EPID: ialn/BA04/B 1 1." iMTA-A O: R: G/ft(N),G'mt(N) X: 



14) MGCP: 200 OK 



17) MGCP: MDCX EPID: l.ihi.T: Mi j/B i @ iMTA-A C: I: cid 1 M: sendrecv L: a:PCMA 



18) MGCP: 200 OK SDP: 



19) SCTP: Q.921: Dalajeq 



20) SCTP: SACK 



SETUP_ACK 



) SCTP: SACK 



Q.931 :A letting 



15)MC)CP:CRCX EPID: g wcpidtffmitw.nel C: 1: cid2 L: a:PCMA M: sendrecv 
R: G/mt(N).G/ft(N) X: X-*:30 SDP: 



Id) MGCP: 200 OK SDP: 



Figure A.1 
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MGC CMS 



Gateway 



I( DISCONNECT 
■4 



HRELEASE- 
COMPLETE) 



54) SCTP :Q.921: Data :req 



55) SCTP: SACK Q.921: Datajnd Q.93 1 : Connect_Ack 



55) SCTP: SACK 



59) MGCP: AUEP EPID: ialn/BA 04/B 1 ly iMTA-A FJ.RM 



60)MGCP:200OKI:cidl RM: restart 



95) MGCP: MDCX EPID: ialn/EA()4/B lis iMTA-A C: I: dill M: inactive L: a:PCMA 



96) MGCP: 200 OK SDP: 



97)MGCP:RQNT EPID: ialn/BA04/B I f iMTA-A Q: R: GTKNI.GmKN) S: L/bz X: 



98) MGCP: 200 OK 



Q.93 1 : Connect 



93) MGCP: DLCX EPID: gwepidlir inn w.nel C: I:ciil2 X: 



99) SCTP: Q.92 1: Data-Ret] C .931 : Disconnec 



100) SCTP: SACK 



115) SCTP: Q.921: Datajntl Q.931: Release 



111) SCTP: SACK 



117) MGCP: RQNT EPID: inln/BA04/l'i 1 '■■■ iMTA-A Q: R: G/I't(N).G/mt(N) 



1 1 8) SCTP: Q.92 1: Datajeq Q.93 1 : Ri lease_conplete 



11 9) MGCP: 200 OK 












120) MGCP: DLCX EPID: 


aln/BA04/B I® iMTA-A C: 


:cidl 








121) MGCP: 250 The connection was deleted P: 




► 



122) SCTP: SACK 



94)MGCP:250OKP 



Figure A.2 



ETSI 



31 



ETSI TS 101 909-24 V1.1.1 (2004-05) 



A.2 Example: Two sides ISDN, iMTA-A release 

Figures A.3 and A.4 illustrate how iMTA-A sets up an ISDN call to iMTA-B; iMTA-A releases the call then. 

iMTA-A MGC CMS iMTA-B 



Layer 2 

.'slahli-hud 



5)MGC >: CRCX EI ] ID: iafa/BA 03 i: I ■■■■■;>! ] \-A C: M inactive Q: L:a:G729 R: G/ft(N>.G/mt(N> 



) SCTP: Q.921: Established 



3) SCTP: Q.92I: Datajnd Q.931: SETUP 



6| MGCP: 200 OK I: eid 1 SDP: 



7) MGCP: RQNT EPID: ialn/BA()2/Bl (■' iMTA-A Q: R: G/li( N}.G/mt(N) S: L/dl 



8)MGCP: 200OK 



9| SCTP: Q.921: Data_Req Q.93 



10) SCTP: SACK 



l| SCTP: Q.92I: Data_Ind Q.93 I : In format io 



!3j MGCP: RQNT EPID: ialn/BAU2/B 1 (»■ iMTA-A Q: R: G/t'uN i.G/nmN") X 



I41MGCP: 200OK 



15| SCTP: Q. 92 I: Data_lnd Q.93 I : Informant 



17| SCTP: Q.921: Data_ind Q.931: Inform 



19| SCTP: Q.921: Datajnd Q.931 : In format io 



15) SCTP: Q.921: Data:ind Q.931: informatic 



27| SCTP: Q.921: Data:ind Q.931 : Infort 



6i SCTP:SACK 



SCTP: SACK 



SCTP: SACK 



SETUP_ACK 



SCTP: SACK 



8i SCTP:SACK 



20 i SCTP:SACK 



26 i SCTP:SACK 



28 i SCTP:SACK 



Z9IMGCP: CRCX EPID: ialii/BAl)l/b [<i<: iMTA-B C:M: inae 
L:a:G729Q: R: G/ft(N),G/mt(N) X: 



IMGCP: 200OKI:cid: SDP: 



Unit_data_req Q.931: SETUP 



32) SCTP: SACK 



37) SCTP: Q.921: Establishjnd 



38) SCTP: SACK 



39) SCTP: Q.921: Datajnd Q.931 : Alerting 



40) SCTP:SACK 



Figure A.3 
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42) SCTP: Q.921: Data_req 



41)MGCP:MDJCX EPID: ialn/BAO l/B I fr* iVITA-B C: I: cid2M: sendonly L:a:G729 
).G/mt(N)X:SDP: 



Q.931: Alerting 



44)MGCP:MDCX EPID: ialii/BA02/B I @ iMTA-A C : I : c id 1 M: sendrecv L: 
R: D/|0-9#*A-D|(N,K),G/t't(N),G 



45) MGCP: 200OKSDP: 



46) SCTP: SACK 



62) SCTP: Q.921: Data_Req 



G729 Q: 
nt(N)X: 



59)MGCP:ME 
Q: R: D/[0- 



-13 i MGCP: 200OKSDP: 



53) SCTP: Q.921: Release_req 



54) SCTP: SACK 



57) SCTP: Q.921: Datajnd Q. 93 1 : Connect 



5S.i SCTP: SACK 



CX EPID: ialn/BA0l/BI6*iMTA-B C: I: cid2M: sendrecv L: a:G729 
A-D](N,K),G/ft(N),G/mt(N) X: 



60) MGCP: 200OKSDP 



61) SCTP: Q.921: Data_req Q.931 : Connect_Ack 



Connected 
talk 



64) SCTP: Q.921: Datajnd Q.931: Connect_Ack 



63) SCTP: SACK 



65) SCTP: SACK 



8)MGCP: AL 



EP EPID: ialn/BAOI/BH"'iMTA-B F: I,RM 



89) MGCP: 200OKI:cid2 RM: restart 



90) SCTP: Q.921: Data.rnd Q.931: Disconnect 



91) SCTP: SACK 



92 )M XP:MDCX EPID: ialn/BAl)2/B I @ iMTA-A C : I : c id 1 M: inactive L:a:G729 Q: R: G/iU- J).G/mt(N)X 



'm MGCP: 200OKSDP: 



MDCX EPID: ialn/BAO l/B 16* iMTA-B C: I: cid2M: inactive L: a:G729 
Q: R: G/t't(N),G/mt(N) X: 



95)MGCP: 200OKSDP 



96) SCTP: Q.921 :Data_Re< 



97) MGCP: RQNT EPID: kilii/BAO l/B I &■ iMTA-A Q: R: G/ft(N),G/mt(N) S: G/cg X: 



98)MGCP: 200 OK 



99) SCTP: Q.921: Data^req Q.931: Disconnect 



105) SCTP: Q.921: Datajnd Q.931: Release_complete 



lOih SCTP: SACK 



) SCTP: SACK 



107) MGCP: DLCX EPID: ialn/BA0:/B 1 (</ iMTA-A C: I: cidl 



108) MGCP: 250P: 



113) SCTP: Q.921: Datajnd Q.931: Release 



15) MGCP: RQNT EPID: ialn/BAO l/B I @ iMTA-A Q: R: G/fU N).G/mt(N) X: 



114) SCTP: SACK 



116) MGCP: 200 OK 



17) MC CP: DLCX EPID: ialn/BAO 1 /B 1 @iMTA -B C: 1: cid2 



120) MGCP: 250 P: 



118) SCTP: Q.921: Data_req Q.931: Release_complete 



Figure A.4 
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A.3 Example: Restart ISDN 



Figure A.5 illustrates a scenario where the restart procedure is invoked once the IUA layer of iMTA-A drops out. 



MGC CMS 



iCTP: Heartbeat 



2) SCTP: Heartbeat_ack 



3) SCTP: Heartbeat 



4)SCT] , :Hcartbcat_ack 



CTP: Heartbeat 



6) ! CTP: Heartbeat 



Endpoint 
..disappears" 



7) ! CTP: Heartbeat 



S^TP: Heartbeat 



9) SCTP: Abort 



14) MGCP: RSIPEPID*/*/*(2>iMTA-A RM: restart 



15)MGCP: 200 OK 



20) MGCP: DLCX EPID: ialn/BAOI/'Ig'jMTA-A 



21) MGCP: DLCX EPID: ialn/B.VU/ ■.■■■All A-A 



22) MGCP: 250 



23) MGCP: DLCX EPID: ia]n/BA01/''(g iMTA-A 



24) MGCP: 250 



25) MGCP: DLCX EPID: ialn/BA()4/ : g iM I A -A 



26) MGCP: 250 



27) MGCP: 250 



29)SCTP:Init_ack 



31) SCTP: Cookie_echo_ack 



33) SCTP: SACK 



34) SCTP: Q.921: ASP_up_ack 



37) SCTP: Q.92 1 : ASP_active_ack 



30)SCTP:Cookie_echo 



32) SCTP 



Q.921:ASP_up 



3:i) SCTP: SACK 



36) SCTP: Q 



921:ASP_activc 



31) SCTP: SACK 



Figure A.5 
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A.4 Example: DTMF Transmission G.723 

Figures A.6 and A.7 illustrate a scenario where iMTA-B calls MTA-A using an ITU-T Recommendation G.723. 1 (see 
bibliography) codec. 

MTA-A MGC CMS iMTA-B 



R in a back 



l)MGCP:AUEPEPlD:aaln/(>K«iMTA A E: I. KM 



2) MGCP: 200 OK RM : restart 



5)MGCP:Ai:EI'EI'ID:aalii/02C»-iMTA A l-:I.RM 



6) MGCP: 200 OK RM : restart 



14) MGCP: CRCX EPID: aaln/01<8 iMTA-A C: M: inactive L:a:G723 Q: 

R:G/ft(N),G/mt(N)X: 



17) MGCP: 200 OK I: SDP: 



1S)MGCP:RQNT EPID: aaln/()K*iMTA-A Q: R: G/ft(N),G/nit(N) S: L/rg X: 



20) MGCP: 200 OK 



21)MGCP:MDCXEPID:aaln/01S>iMTA-A C: I: M: sendonly L: a:G723Q: 
R:G/ft(N),G/mt(N) S: L/rg,G/rtg>cid 1 X: SDP: 



241 MGCP: 200 OK 



30)MGCP: MFV EPID: aalii/ll] » iMTA A X: (): L/hd 



31)MGCP:200OK 



32) MGCP: MDCX EPID: aaln/01 @iMTA-A C: M: sendrecv L: a:G723 Q: 
R: D/[0-9#*A-D](N,K),G/ft(N),G/mt(N) X: 



33) MGCP: 200 OK 







39)MGCP:AUEPEPID 


aaln/01@iMTA-AF:I;RM 


40) MGCP: 


200OKRM: 


restart 










41 ) MGCP: AUEP EPID: aaln/02@ iMTA-A F 


I;RM 


42) MGCP 


200OKRM 


restart 






43) MGCP 


NTFY EPID 


aaln/01<s> iMTA-A X: O: D/2 












44) MGCP: 


200 OK 



4) SCTP: Heartbeat_ack 



1DMGCP: 
R: Qft(N),G/ 



EPID: ialn/BA01/Bl@ iMTA-B C:M: inactive L:a:G723Q: 
mt(N)X: 



19) MGCP: MI 
R: D/[0-» 



EPID: ialn/BAOl/Bl® iMTA-B C:M: sendrecv L:a:G7 23 Q: 
A-D](N,K),G/ft(N),G/mt(N)X: SDP: 



R: D/[0-9# 



3) SCTP: Hcalbeal 



7) SCTP: Q.921: Release 



9) SCTP: Q.921 : Datajnd Q.93 1: Setup 



10) SCTP: SACK 



12)MGCP:200OKI: SDP: 



13) SCTP: Q.921 : Release Q.931 : Setup_Ack 



15) SCTP: Q.921: Release Q.931: Alerting 



16) SCTP: SACK 



22) SCTP: Q.921 : Release Q.931 : Progress 



23) MGCP: 200 OK 



25) SCTP: SACK 



34) SCTP: Q.921: Release Q.931: Connect 



35) SCTP: Q.921 : Release Q.93 1 : Connect_ack 



36) SCTP: SACK 



37) MGCP: CRCX EPID: ialn/BAOl/B I @ iMTA-B F: I,RM 



38) MGCP: 200 OKI: RM: restart 



45) MGCP: RQ^T EPID: ialn/BA01/Bl@iMTA-B Q: 



A-D](N,K),G/ft(N).G/mt(N) S: D/2X: 



Figure A.6 
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53)MGCP:RQNT EPID: aa ln/0 1 <3> iM T A - A Q 
R: D/[0-9#*A-D](N,K),G/ft(N),G/mt(N) S: D/6 X 



54)MGCP: 200OK 



102) MGCP: MDCX EPID: aaln/01S>iMTA-A C:M: inactive L: a:G723 Q: 

R:G/ft(N),G/mt(N)X: 



107) MGCP: 200 OK 



108) MGCP: RQNT EPID: aaln/01 ®>iMTA-A Q: R: G/ft(N).G/mt(N) S: G/cg X 



111) MGCP: 200 OK 



114) MGCP: AUEP EPID: aaln/02S>iMTA-A F: I.RM 



52) MGCP: 20C 



71)MGCP:AU 



EP EPID: ialn/BAOI/B 1 @ iMTA-B F: I.RM 



73) MGCP: AU 



EPEPID: ialn/BA 02/B1® iMTA-B F: I.RM 



77) MGCP: AU 



EP EPID: ialn/BA02/B I @ iMTA-B F: I.RM 



83)MGCP:Al 



95) MGCP: Al 



101) MGCP: 

B c/ftiN; 



46)MGCP:200OK 



51)MGCP:NTFYEPID: ialn/BA 01/B 1@ iMTA-B O: D/6 X 



59) SCTP: Heatbeal 



60)SCTP:Heartbeat_ack 



69)SCTP:Heatbeat 



70)SCTP:Heartbeat_ack 



72) MGCP: 200 OK I: RM: restart 



76) MGCP: 200 OKI: RM : restart 



78)MGCT: 200 OK I: RM : restart 



81)SCTP:Heatbeat 



82) SCTP: Heartbeat_ack 



EP EPID: ialn/BA 01/B I @ iMTA-B F: I.RM 



84) MGCP: 200 OK I: RM : restart 



93) SCTP: Heatbe 



94) SCTP: Heartbeat_ack 



EPEPID: ialn/BA 02/B1® iMTA-B F: I.RM 



96) MGCP: 200 OK 1: RM: restart 



97) MGCP: A JEP EPID: ialn/BA 02/B2® iMTA-B F: I.RM 



98 ! M GCP: 200 OK I: RM : restar 



99) SCTP: Q.921: Datajnd Q.931 : Disconnecl 



100) SCTP: SACK 



EPID: ialn/BA01/B18> iMTA-B C: I:M: inactive L:a:G723 Q: 
OmllNIX- 



103) MGCP: 200 OK 1: RM: restart 



105) SCTP: Q.921: Release Q.93 1: RELEASE 



109) SCTP: SACK Q.921: Release Q.931: Re lease-Co mp let. 



110) SCTP: SACK 



XX EPID: ialn/BA0]/B 1@ iMTA-B C: I: 



113) MGCP: 250 P: 



Figure A.7 



A. 5 Example: FAX call from ISDN to analog 

iMTA-B calls MTA A that is an analogue FAX. The endpoints communicate initially with each other using ITU-T 
Recommendation G.729 [18] a codec. Once the FAX tone has been detected, switch-over to ITU-T Recommendation 
G.711 [17] takes place. 
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59) MGCP: CRCK EP1D: ialn/BA!) l/B l @ iMTA-B C:M: inactive L:a:G729 Q: R: G/ft(N),G/mt(N) X: 



61)MGCP: RC 



NT EPID: ia ln/BAO l/B I @ iMTA-B Q: R: G/ft(N),G/mt(N) S: L/dl X: 



89) MGCP: CRCX EPID: aaln/02@iMTA-A C: M: inactive L: a:G729 Q: 

R: G/ft(N),G/mt(N)X: 



91) MGCP: 200 OK: SDP: 



92) MGCP: RQNT EPID: aaln/02@iMTA-A Q: 
R: G/ft(N),G/mt(N),X-P/oc(N),X-P/of(N) S: X-P/ir X: 



93) MGCP: 200 OK: 



95) MGCP: NTFY EPID: aaln/02@iMTA-A X: O: X-P/oc(X-P/ir) 



9) SCTP: Q.921 : Established 



0) SCTP: SACK 



1) SCTP: Q.921: Data_ind Q.931: Facility 



2) SCTP: SACK 



13) SCTP: Q.921: Data_rcq Q.931: Facility 



14) SCTP: SACK Q.921: Data_ind Q.931: Facility 



15) SCTP: SACK 



16) SCTP: Q.921: Data_req Q.931: Facility 



17) SCTP: SACK Q.921: Data_ind Q.931: Facility 



18) SCTP: SACK 



19) SCTP: Q.921: Data_req Q.931: Facility 



20) SCTP: SACK 



43) SCTP: Q.921: Re leas 



■141 SCTP: SACK 



55) SCTP: Q.921: Established 



56) SCTP: SACK 



57) SCTP: Q.921: Data_ind Q.931: Setup 



58) SCTP: SACK 



60) MGCP: 200 OK 1: SDP 



62) SCTP: Q.921: Data_rcq Q.931: Setup_ack 



63)MGCP: 200 OK 



64) SCTP: SACK 



69) SCTP: Q.921: Data_ind Q.931: Inforn 



70) SCTP: SACK 



71) MGCP: RQ^T EPID: ia ln/BAO l/B 1 @ iMTA-B Q: R: G/ft(N),G/mt(N) X: 



73JMGCP: 200OK 





75) SCTP 


Q.921 


Dala_ 


nd Q.931: information 


76) SCTP: SACK 




77) SCTP 


Q.921 


Data_ 


nd Q.931: Information 


78) SCTP: SACK 




79) SCTP 


Q.921 


Dala_ 


nd Q.931: Informalion 


80) SCTP: SACK 



85) SCTP: Q.92 1 : Datajnd Q.93 1 : Information 



86) SCTP: SACK 



87) SCTP: Q.921: Datajnd Q.931: Information 



88) SCTP: SACK 



90) SCTP: Q.921: Datajeq Q.931: Alerting 



94) SCTP: SACK 



Figure A.8 
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FAX lone 
detection 

Switch to 
G.7H 



96) MGCP: 200 OK 



97) MGCP: MDCX EPID: a a In /02@ iMTA-A C: I: M:sendonly L: Q: R: S:X: SDP: 



lOllMGCP: 200OK 



"►> 



103) MGCP: RQNT EPID: aaln/02@ iMTA-A Q:S: X 



104) MGCP: 200 OK 



105) MGCP: NT FY EPID: :ialn/02@ iMTA-A O: LA>c< L/adsi) 



106) MGCP: 200 OK 



15) MGCP: RQNT EPID: aaln/02@iMTA-A Q: R: G/fl(N),G/mi(N) 
S:L/rg,G/rt@cidlX 



116)MGCP: 200OK 



19) MGCP: NTFY EPID: aaln/02© iMTA-A X:0: L/hd 



20) MGCP: 200 OK 



121) MGCP: MDCX EPID: aaln/02@ iMTA-A C:M: sendrecv L: a:G729 Q: 
R: D/[0-9#*A-D"](N,K).G/fl(N).G/mi(N) X 



122) MGCP: 200 OK 



123) MGCP: RQNT EPID: aaln/02@iMTA-A Q: 
R: D/[0-9#*A-Dl(N,K),L/hf(N.K),G/fl(N),G/mt(N) X 



125) MGCP: 200 OK 



127) MGCP: NTFY EPID: aaln/02@ iMTA-A X O: G/fl 



28) MGCP: 200 OK 



<) MGCP: MDCX EPID: aaln/02@ iMTA-A C: I: M : sendrecv L:a:PCMA X-*: 100 SDP: 



132) MGCP: 200 OK SDP: 



142) MGCP: 200 OK I:RM:restai 



171) MGCP: AUEP EPID: aalii/0 I @ iMTA-A F: I.RM 



172) MGCP: 200 OK 1: RM: restart 



19) SCTP:Q.921: Data_rcq Q.931 : Progrt 



XEPID: ialn/BA01/Bl@iMTA-B C: I: M:sendonIy L:Q: R: X: SDP: 



100) MGCP: 200 OK 



102) SCTP: SACK 



!4) SCTP: Q. 921: Daia_ret| Q. 93 1 : Connect 



126) SCTP: SACK 



30) MGCP: MDCX EPID: iain/BAOl/B I @ iMTA-B C: I: M :sendrecv L: a:PCMA X-*: 1 



131) MGCP: 200 OK 



151) SCTP:Q.921: Dala_ind Q. 93 1 : Facility 



152) SCTP: SACK 



153) SCTP: Q.921: Dala.req Q.931:Faci 



154) SCTP: SACK Q.921: Data_ind Q. 93 1 : Facility 



155) SCTP: SACK 



156) SCTP: Q.921: Daia_req Q. 93 1 : Facility 



157) SCTP: SACK Q.921: Daia_ind Q. 93 1 : Facility 



158) SCTP: SACK 



159) SCTP: Q.921: Daia_rcq Q. 93 1 : Facility 



160) SCTP: SACK 



212) SCTP: Q.921: Dala_ind Q.931: Disconnect 



215) SCTP: SACK 



Figure A.9 
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23 5) MGCP: 200 OK 



23 2) MGCP: ROM EPl D: aaln/02 (<■ iMTA-A Q: R: G/muN) S: X: 



233) MGCP: 200 OK 



23 4) MGCP: RQNT EPl D: aaln/02 (<■ iMTA-A Q: R: G/niUN) S: X: 



236) MGCP: DCLX EPID: aaln/02 @iMTA-A C: I: 



237) MGCP: 250 OK P: 



260) SCTP: Q.921:Release_ind 



261) SCTP: SACK 



270) SCTP:Q.921:Establish_ind 



271) SCTP: SACK 



272) SCTP: Q.921: Data_ind Q.931 : Facility 



273] SCTP: SACK 



274) SCTP: Q.921: Dala_req Q.931: Facility 



275) SCTP: SACK Q.921: Data_ind Q.931 : Facility 



276) SCTP: SACK 



277) SCTP: Q.921: Dala_req Q.931: Facility 



27 8) SCTP: SACK Q.921: Data_ind Q.931 : Facility 



279) SCTP: SACK 



280i SCTP: Q.921: Data_req Q. 93 1 : Facility 



281) SCTP: SACK 



304) SCTP: Q.921: Release_ind 



305) SCTP: SACK 



Figure A.10 
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Annex B (informative): 

iMTA configuration parameters 



This annex provides information on the configurable parameters in the iMTA. The shown default parameters are 
understood to be typical example values; other appropriate values instead MAY be configured too. 



B.1 Q.921 parameters 



Table B.1 : Q.921 Parameters 



Parameter 


Default value 


Example 


Layer 2 status 


non-permanent 


permanent/non-permanent 


Layer 2 configuration 


point-to-multipoint 


point-to-point/point-to-multipoint 


TL2out 


7s 


Timer for periodically layer 2 re-establishment attempts in case of 
permanent layer 2 (timer between 4 s and 60 s). 



B.2 SCTP/IUA parameters 



Table B.2: SCTP/IUA Parameters 



Parameter 


Default 
value 


Purpose 


Rtolnitial 


3 000 ms 


Initial round trip timeout 


RtoMin 


1 000 ms 


Initial minimum round trip timeout 


RtoMax 


60 000 ms 


Initial maximum round trip timeout 


ValidCookieLife 


60 000 ms 


Lifetime of a cookie 


AssocMaxRetransmits 


10 


Maximum retransmissions per association 


PathMaxRetransmits 


8 


Maximum retransmissions per path 


MaxInitRetransmits 


8 


Maximum initial retransmissions 


MyRwnd 


28 000 


Number of bytes queued in rev queue 


Delay 


200 ms 


According RFC 2960 [28] MUST NOT be > 500 ms 


MaxSendQueue 


20 


Number of chunks in send and retransmission queue 


MaxRecvQueue 





Number of chunks in rev queue: 

- 0: only number of bytes will be supervised; 

- > 0: then a_rwnd will be set to if 
noOfChunkslnReceptionQueue > maxRecvQueue 


MaxMessageslnFlight 





Limits the number of chunks sent to the peer without 
acknowledgement 


NoOflnStreams 


9 


Number of streams per association from the different peers 


NoOfOutStreams 


9 


Number of streams per association to the different peers 


NoOfAssociations 


2 


Maximum number of associations 



B.3 Tones 

Values for vendor/country-specific tones SHOULD be configurable. 
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